\chapter*{RAT или Рендерим Визуально}
 
Прежде всего, введём в употребление некоторые
    аббревиатуры, используемые в Пиксаровских продуктах.
    Итак:
  
     prman –
      PhotoRealistic renderMAN или, официально, Pixar’s
      RenderMan – собственно, рендерер от Пиксар. Я уже использовал это
      обозначение раньше, теперь просто приведу его для
      закрепления.

     RAT
      – Renderman Artist Tools – набор инструментов и
      плагинов для связи Maya и prman. Если кто-то называет его “крысой”
      – знайте, перед вами новичок. Закоренелый трёхмерщик непременно
      назовёт его “рат” (а не “рэт”, как этого следовало бы ожидать, и уж
      никак не “ЭрЭйТи”).

     MTOR
      – Maya To Renderman – собственно плагин
      для Maya, который позволяет ей рендерить при помощи
      Renderman-совместимых рендереров. Входит в состав RAT.

 Продуктовая линейка Пиксар на момент написания этих
    строк включает в себя 3 продукта: Renderman Pro Server (включающий
    в себя prman, Irma и Alfserver), RAT (в составе MTOR, Slim, Alfred,
    “it”) и Renderman For Maya. Нужно было бы, конечно, для
    лицензионной чистоты расставить в предыдущей фразе значки ™ в
    произвольном порядке, ну да ладно.

 Ещё раз - для того, чтобы хоть что-то отрендерить,
    вам понадобится Pro Server. Для того, чтобы связать Maya и Pro
    Server, нужен RAT:

 \gr{image007}

 Renderman for Maya - отдельный новый продукт,
    являющийся боковой веткой эволюции prman и RAT, предназначенный для
    более удобной увязки этих продуктов и нацеленный, в первую очередь,
    на людей, ранее с Renderman не сталкивавшихся. Мы не будем
    рассматривать Renderman For Maya в этой главе детально, поскольку
    на момент подготовки этой главы продукт всё ещё не был выпущен в
    продажу и не был доступен для бета-тестирования.

Для
    любознательных: само название
    RenderMan имеет очень интересную историю. В самом начале у
    основателей Pixar был vision – они хотели создавать “железо”,
    аппаратные решения для рендеринга. В идеале, такой микрокомпьютер
    должен был быть очень маленьким и носимым чуть ли не в кармане. Из
    таких компьютеров создавались бы “render walls”, объединяющие свои
    усилия в рамках одной задачи; производством такого железа могли
    заниматься кто угодно – но оно было бы полностью совместимым,
    поскольку подчинялось бы стандарту Renderman. По аналогии с
    появившимся в то время карманным плейером для кассет фирмы Sony,
    который назывался Walkman, будущее устройство назвали
    Renderman.

Новый микрокомпьютер
    так никогда и не появился в продаже, но имя – и стандарт –
    прижились.
  
\section*{MTOR}

 Первое, с чем столкнётся пользователь Maya, установивший комплект из Pro Server и RAT (а работать с ними он будет именно в такой связке)
– это MTOR. В интерфейсе MAYA это проявится вот таким вот образом:

\gr{image009}

 то есть в вашем меню появится новый пункт – RenderMan:

\gr{image011}

 Что произойдёт после того, как вы (предварительно
    загрузив какую-нибудь существующую сцену), выберете пункт меню
    RenderMan=>Render? А произойдёт вот что: MTOR последовательно
    обойдёт все элементы сцены и {\it постарается} вывести их в файл
    формата RIB. Кроме того, он пройдётся по геометрии и источникам
    света и назначит для них шейдеры в RIBе – но сделает это очень
    хитро: фактически, MTOR не будет учитывать текстуры и сложные
    материалы, эмулируя лишь некоторый стандартный набор шейдеров
    (Ambient Light, Directional Light, Point Light, Spot Light, Phong,
    Blinn, Lambert – эти шейдеры легко опознать по сигнатуре имени
    файла mtor*.slo). Наконец, будет запущен рендеринг, который вызовет
    окно Alfred и выведет результаты в окне it.

 Как видите, всё переплелось и взаимосвязалось.
    Попробуем разобраться в клубке из аббревиатур и программ, и сделаем
    это с помощью простого тестового примера.

 Набросайте в сцену несколько примитивов и добавьте
    источники света – пусть это будет простой майский
    directLight:

 \gr{image013}

 В общем, уже можно рендерить. Что мы и делаем:
    RenderMan=>Render.

 Мы только что вызвали на выполнение MTOR – плагин,
    позволяющий Maya рендерить  с помощью Renderman-совместимых
    рендереров. Плагин этот встраивается в интерфейс Maya, но поскольку
    был написан достаточно давно, ещё во времена первых версий Майки,
    когда встраиваться в Render Globals и Rendering Window не
    позволялось – проявляется в виде меню и вызываемого из этого меню
    набора собственных окон.

 На плечах MTOR лежит задача вывода геометрии в
    формат RIB и вызова других программ из набора. Также он
    осуществляет поддержку Renderman-compatible subdivision surfaces в
    интерфейсе Maya – видите в меню RenderMan последний пункт? Это
    оно.

 Сильной стороной MTOR является его
    программируемость. Встраиваясь в Maya, MTOR добавляет несколько
    новых команд Mel; более того, будучи сам написан на языке
    программирования Tcl, MTOR позволяет также выполнять скрипты на
    этом языке, что делает его необычно гибким в применении и адаптации
    к различным пайплайнам.

 По моему мнению, RAT – это попытка технарей из
    Pixar усидеть сразу на двух стульях, а именно - сделать
    одновременно удобный для неопытного и расширяемый опытным
    пользователем продукт. В общем, где-то табурет у них и получился –
    пользоваться более-менее удобно, ручки все на месте, настроить под
    свои требования – тоже можно. С другой стороны, у такого подхода
    есть и свои проблемы, но о них потом.
  
\section*{Alfred}

 А у нас тем временем (сцена несложная и много
    времени на экспорт в RIB не ушло) появляется окно
    Alfred:

 \gr{image015}

 Alfred – система распределения рендеринга по
    локальной сети. Даже если вы не используете сетевой рендеринг, эта
    система будет установлена и включена по умолчанию. Это может
    пригодиться, например, если у вас многопроцессорная система; в
    таком случае вы сделаете вид, что у вас на самом деле 2 компьютера
    – и voila.

 Alfred – достаточно продвинутый сетевой инструмент,
    который используют во многих студиях не только в составе RAT, но и
    для сетевого рендеринга из Maya, 3dsmax и даже After Effects, Shake
    и Nuke, благо под Renderman он не заточен, а в качестве файла
    задачи в нём выступает обычный Tcl скрипт с командами. Но несмотря
    на такую гибкость и на то, что Alfred используется в работе {\it самими} Pixar, качество
    кода этого продукта от релиза к релизу заметно ухудшается и потому
    в последнее время появилась тенденция ухода студий на
    альтернативные (в том числе и собственной разработки) сетевые
    диспетчеры.

 Раз уж мы заговорили об Альфреде, обозрим и его
    лучшего друга – Альфсервер.
  \section*{Alfserver}

 Alfserver – это собственно агент, выполняющий
    задания Alfred. Название этой программы несколько сбивает с толку,
    поскольку мы привыкли, что сервером называется одна головная
    программа, к которой подсоединяется множество клиентов. В данном
    случае центрального рендеринг-сервера, раздающего задачи клиентам,
    нет и применяется обратная аналогия – клиент-диспетчер задач один
    (это Alfred) и он сам распределяет задачи по серверам (Alfserver),
    установленных на рендеринг-машинах в ферме. Очевидно, что клиентов
    может быть много (скажем, клиент может быть установлен на
    компьютере у каждого аниматора и работать по ночам, пока аниматору
    снятся анимационные кривые), и все они будут распределять свои
    задачи по серверам.

 Для
    продвинутых: конечно, всё не так
    просто. При работе с Alfred существует
    возможность использовать утилиту {\it maitre\_d}, которая будет
    выступать в качестве центрального сервера – но основноё принцип
    работы от этого не изменится, поскольку утилита эта сама
    распределять задачи не может, а всего-лишь собирает информацию о
    занятости систем и прочих метриках и раздаёт её всем желающим – и
    локальные диспетчеры используют эти метрики для оптимизации
    нагрузки рендеринг-фермы.
  \section*{It}

 А тем временем мы почти сразу же после появления
    окна Alfred видим новое окно – it - в котором быстро проявляется
    наша картинка:

 \gr{image017}

 “it” (Image Tool)– в оригинале вьюер для
    графических файлов, в последних версиях вобравший в себя
    функциональность просмотрщика последовательностей, каталогизатора
    файлов и даже композера. Я более чем уверен, что большинство
    пользователей RAT не используют даже 50\% возможностей этой
    программы – а зря.

 По умолчанию it выступает в качестве display target
    при рендеринге; это удобно, если вы хотите посчитать несколько
    различных картинок подряд, а затем сравнить их или выбрать лучшую
    из серии.

 Сравним полученную картинку с результатом
    рендеринга при помощи родного движка от Maya:

 \gr{image019}

 Очень похоже, не правда ли? Ничего, в общем,
    удивительного – сцена примитивная и потому нашему крутому рендереру
    prman негде было развернуться во всей своей красе.

 Вы наверняка заметили, что размеры картинок,
    полученных при рендеринге через RAT и родным рендерером Maya, не
    совпадают. Самое время узнать, каким образом настраивается RAT – а
    именно, вызвать RenderMan=>RenderMan Globals.

 \gr{image021}

 Подробное описание всех функций этого окна оставим
    для документации по RAT – кстати говоря, несмотря на некоторую
    запутанность и огромный размер, она обладает одним немаловажным
    преимуществом – в ней есть ВСЁ.

 Пытливый читатель уже обнаружил параметр Display
    Resolution. На нашем скриншоте этот параметр уже выставлен в 0, 0 –
    таким образом мы всегда будем рендерить в размере выбранного
    viewport’а Maya; по умолчанию же этот параметр выставлен в 640x480.
    Кстати говоря, обратите внимание на значки i рядом с именами параметров –
    это контекстная справка. Про возможность установки (0,0) я узнал
    именно из неё.

 Для
    любознательных: как видите, разрешение
    рендеринга в Maya и RAT не сихронизированы. Оставим для других
    обсуждение правомерности этого поступка; сами же скажем, что задачу
    эту можно достаточно просто решить с помощью механизма скриптования
    MTOR – для этого достаточно немного покопать в документации в
    сторону RibBox, mattr и Майского нода resolution.
  
\section*{SLIM}

 Вернёмся к MTORу. Чего он делать, к сожалению, не
    умеет – так это конвертировать майские материалы в рендерменовские
    шейдеры. По идее разработчиков RAT, этого от программы и не
    требуется, поскольку считается, что все шейдеры будут либо писаться
    руками, либо создаваться при помощи SLIM – визуального конструктора
    шейдеров.

 О SLIMе можно говорить очень долго. После
    Hypershade он может показаться несколько архаичным, но тем не менее
    является достаточно удобным конструктором для шейдеров.

\gr{image023}

 SLIM, как и Hypershade, реализует древовидную схему
    построения шейдеров из блоков, но не использует при этом
    визуализацию в виде дерева (такая визуализация появилась в
    последних версиях, но не является особо функциональной и потому
    зачастую попросту не используется).

 Для
    любознательных: древовидная схема для
    визуального построения шейдеров – да и вообще для визуального
    построения алгоритмов и программ, которыми и являются шейдеры –
    идея абсолютно не новая и уже серьёзно заезженая. В том или ином
    виде, визуальные конструкторы шейдеров в виде деревьев используются
    уже практически во всех современных системах анимации и
    рендеринга.

 На самом
    деле, когда я занимался историей этого вопроса, для того чтобы
    кратко осветить его в этой вставке для любознательных, я был
    буквально ошеломлём тем количеством информации, которая доступна в
    Интернете по поводу Визуального Программирования – а ведь
    визуальное построение шейдеров суть визуальное программирование и
    есть.

 Как
    оказалось, первая графическая компьютерная система,
    продемонстрированная в 1963 году Сазерлендом (она называлась
    SketchPad – для тех, кто уже запустил верный Google) уже была
    оснащена визуальным редактором для быстрого построения программ – и
    количество разработанных с тех пор систем визуального
    программирования огромно.

 Так почему же
    мы до сих пор не строим все наши программы визуально? Почему
    программисты шейдеров в той же Пиксар до сих пор пользуются vi и
    emacs, создавая свои сотни тысяч строк кода шейдеров (цифры
    реальные)? Этому можно посвятить отдельную статью, а то и книгу;
    скажем лишь, что у визуального представления программ есть некий
    порог сложности, начиная с которого их становится сложно
    редактировать и эта возрастающая сложность редактирования и
    понимания нивелирует все достоинства метода.

 Создаваемые в SLIM материалы назначаются на
    геометрию в Maya, добавляя к шейпам новые кастомные атрибуты с
    необходимой для MTOR информацией.

 Более того, таким же образом (через кастомные
    атрибуты из SLIMа) вы можете добавлять в сцену свой собственный
    RIB-код при помощи так называемых RIBbox (мы их уже упоминали в
    отступлении для любознательных).Дальше – больше: расширяемый, как и
    сам MTOR, при помощи Tcl, SLIM позволяет вставлять в сцену
    TCLbox’ы, которые будут исполняться на этапе экспорта сцены в RIB и
    имеют полный доступ как ко внутренним интерфейсам самой Maya, так и
    к командам MTOR и SLIM.

\begin{quotation}
Для любознательных: основной атрибут шейдера называется slimSurf; короткое имя, под которым он фигурирует в скриптах и в файлах *.ma –
sss. Выглядит в Maya Ascii-файле это примерно так:
\end{quotation}

\code{code/ex1.ma}

 Вернёмся к нашим тестовым баранам. Давайте теперь
    немного усложним нашу сцену. Поработайте немного над вашими
    примитивами. Раз уж заговорили про парнокопытных, то у вас должно
    получиться что-то вроде этого:

 \gr{image025}

 Не получилось? Не расстраивайтесь, у меня тоже не
    получилось, поэтому я просто взял готовую модель (автор модели –
    Ник Габченко, за что ему отдельное спасибо) из файла sheep.ma (вы
    можете найти его на диске).

 Эта модель – полигоны, переведённые в subdivision
    surfaces при помощи команды Modify=>Convert=>Polygons to
    Subdiv. Давайте опробуем SLIM на деле и назначим овечке материалы.
    Renderman=>Slim=>New Palette.

 \gr{image027}

 В меню SLIM выбираем File > Create Appearance
    > Surface > Velvet – пусть овечкина голова будет бархатной.
    Двойной клик по шейдеру Velvet, клик по области Preview:

 \gr{image029}

 Как видите, это довольно сильно напоминает Attribute Editor для
    стандарных майских материалов.

 Темноватый бархат получается, сделаем его немного
    светлее. Изменяем Kd, поскольку амбиентного источника у нас в сцене
    не будет (говорят, иметь их в сцене вредно), изменяем цвет, всё
    время проверяем результат, кликая на шарике. Добившись вменяемого
    результата, назначаем созданный материал: в Maya выбираем голову
    овечки, затем в основном окне SLIMа выбираем Appearance=>
    Attach. Рендерим (вы уже вынесли пункт меню RenderMan=>Render на
    полку?)

 \gr{image031}

 И чтобы уже совсем сделать наш краткий туториал
    похожим на все остальные 1327 туториалов для начинающих,
    заполонивших Интернет, покажем, как собственно делаются в SLIMе
    более сложные составные шейдеры.

 Для
    любознательных: число 1327 выбрано
    случайно. Кстати, о случайных числах – вот вы знаете, например, как
    отличить TIFF файл по сигнатуре? Оказывается, очень просто – у него
    3им и четвёртым байтом записано число 42 – как сказано в
    спецификации, an arbitrary but carefully chosen number (42) that
    further identifies the file as a TIFF file. Я думаю, вопрос о том,
    почему выбор не пал на  43 или 41 – неправомерен, поскольку они не являются 5ым Каталонским
    Числом.

 Так вот, рядом с Velvet color кликнем на жёлтом
    квадратике и в выпавшем меню выбираем Connection. В этом же строке
    справа в вываливающемся списке выбираем Noise. Должно получиться
    что-то такое:

 \gr{image033}

 После клика по кнопке Noise мы попадаем в редактор
    уже самого шума.

 И опять для
    любознательных: придумал нойз и
    первым реализовал шейдеры в продакшн рендеринге один и тот же
    человек – Кен Перлин.

 Быстренько задираем величину frequency в заоблачные
    дали (а именно, где-то в 10), кликом по диагональной стрелочке
    возвращаемся к исходному Velvet и сразу же видим результат на нашей
    овечке:

  \gr{image035}

 Исправить ситуацию с UV-меппингом головы овечки,
    из-за которой нойз так постыдно размазался, мы оставим в качестве
    домашнего задания для читателей, а сами закончим наш туториал на
    самом интересном месте и продолжим рассматривать программы и
    утилиты, входящие в состав RAT. Их осталось не так уж и много.
    Честно скажем, осталась одна
  
\section*{Irma}

 Irma – ре-рендерер. В общем, идея проста – вы
    рендерите один раз с помощью Ирмы, которая кэширует необходимую
    информацию о сцене, освещении и шейдинге. Все последующие разы
    ре-рендеринг использует эту информацию и происходит гораздо
    быстрее, без перегенерации RIB-файлов и шейдеров. Irma понимает
    изменения параметров шейдеров, позиции источников света и изменения
    в координатных системах – такие изменения будут просчитаны очень
    быстро. Ближайший аналог Irma из мира Maya – это, конечно же,
    IPR.

 Что бы не говорили, а бОльшую часть интересных
    новых идей уже кто-то придумал до нас. Взять, например, ту же Ирму
    с IPRом. Самая первая реализация шейдеров в продакшне – та самая,
    которую реализовал на Фортране Кен Перлин – использовала те же
    идеи: предварительный рендеринг всего, что можно, в буффер и
    последующее наложение шейдеров. С другой стороны, с тех пор утекло
    очень много воды, и в современных рендерерах бОльшую часть времени
    тратится именно на шейдеры. Тем полезнее для вас будет
    Ирма.
